-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix compilation for target x86_64-unknown-linux-musl
.
#1180
Conversation
bors try |
bors try- |
bors try |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from that 1 comment, it looks good to me!
Some(read_xmm(&fpregs._xmm[15])); | ||
// Skip reading floating point registers when building with musl libc. | ||
// FIXME: Depends on https://github.com/rust-lang/libc/pull/1646 | ||
#[cfg(not(target_env = "musl"))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to handle the other case too? Like
#[cfg(target_env = "musl")]
unimplemented!("blocked on https://github.com/rust-lang/libc/pull/1646");
Or will it work fine as-is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is on the always-taken path for fault handling so panicking here will break things that depend on fault handling, like middlewares. Now all XMM registers will be defaulted to zero if not dumped; do you think it is fine?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I'm not familiar enough to know what the impacts of that are: if you think this leaves the system in a sensible state where execution makes sense then I'm happy with it! Otherwise, I don't think compiling and failing silently is necessarily a step up from panicking or not compiling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only case where doing so is possibly incorrect is when we take a managed snapshot and then unwind out from WebAssembly code (where floating point state will be lost). This feature is not widely used (yet) and I think it is "cold" enough to ignore for now and defer to after a future upstream fix in musl-libc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, that sounds reasonable to me! We just need to remember to not forget to update this!
tryBuild succeeded
|
bors r+ |
1180: Fix compilation for target `x86_64-unknown-linux-musl`. r=losfair a=losfair Fixes compilation failure when built for `x86_64-unknown-linux-musl`. - Allows disabling the `wabt` feature to avoid depending on a C++ compiler. - Disables XMM register dump on fault as a workaround for missing musl libc types (rust-lang/libc#1646). Fixes #1178 and #1173 . Co-authored-by: losfair <[email protected]>
Build succeeded
|
Fixes compilation failure when built for
x86_64-unknown-linux-musl
.wabt
feature to avoid depending on a C++ compiler.Fixes #1178 and #1173 .